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DETAILED ACTION 

Claims 1, 6, 8, 11-13, 15, 1 8-22, 26, 27, 30, 32, 33, 39, and 40 are pending for 

examination. 

Claim 8 is amended. 

Claims 1 , 6, 8, 1 1 -1 3, 1 5, 1 8-22, 26, 27, 30, 32, 33, 39, and 40 are rejected. 

Response to Arguments 

1 . Applicant's arguments filed with respect to claim 1 1 have been fully considered 
but they are not persuasive. Applicant argues that cited references Pesce (US 7 328 
278), Sankaran (US 2003/0231587), and Gaddis (US 7 554 930) do not teach the 
limitations of the claim. Examiner disagrees. 

2. As per claim 1 1 , applicant argues that cited references do not teach utilizing a 
metric. Both Gaddis and Sankaran teach utilizing a path metric such as AS_Path 
(Gaddis column 6, lines 44-58, Sankaran paragraph 32), in addition to the metric utilized 
by Pesce to determine table information and which routes to maintain within the table. 
As such, it would have been obvious to one of ordinary skill in the art at the time of the 
invention to utilize metrics for links such as taught by Gaddis and Sankaran as the 
metric described by Pesce, as AS_Path is a metric knows to be used in the art of 
network routing (Gaddis, column 6, lines 44-46). Applicant further argues that cited 
references do not teach clearing routes from the table when a limit is reached. As cited, 
Sankaran teaches removing redundant routes from the table, thus clearing those routes 
from the table, and as a result, the table being altered from its original form as a result 
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of the threshold being reached (paragraph 35). As such, the previous rejection of claim 
11 is maintained. 

3. With respect to claims 1 , 8, 18, 27, and 33, applicant relies on arguments similar 
to those presented with respect to claim 1 1 , and as such, examiner relies on arguments 
presented in response. The previous rejections of claims 1, 8, 18, 27, and 33 are 
maintained. 

Claim Rejections - 35 USC § 103 

4. The text of those sections of Title 35, U.S. Code not included in this action can 
be found in a prior Office action. 

5. Claims 1,8,11-13,15,1 8-22, 26, 27, 30, 33, 39, and 40 are rejected under 35 
U.S.C. 103(a) as being unpatentable over US 7 328 278, Pesce et al, US 
2003/0231587, Sankaran et al, and US 7 554 930, Gaddis et al. 

6. As per claim 1 , Pesce teaches a method comprising: 

routes exported from an exterior routing protocol executing on a network device 
to an interior routing protocol executing on the network device (column 2, lines 51-64, 
where the network element may contain multiple routing databases including those that 
may run both interior and exterior routing protocols, also column 3, lines 23-28, where 
the routing information may be exported from one database operating in one protocol to 
another database operating in another protocol); 

maintaining routes exported from the exterior routing protocol executing on the 
network device to the interior routing protocol executing on the network device (column 
2, lines 51-64, where the network element may contain multiple routing databases 
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including those that may run both interior and exterior routing protocols, also column 3, 
lines 23-28, where the routing information may be exported from one database 
operating in one protocol to another database operating in another protocol); and 

blocking routes exported from the exterior routing protocol to the interior routing 
protocol (column 4, lines 52-61 , where the updated mappings may be blocked by the 
manager); 

updating routing information to associate the routes with a maximum metric that 
defines a maximum distance from the network device to neighboring network devices 
(column 5, lines 14-16, where each entry in the table may be associated with a metric 
value and scale, also column 1 1 , lines 52-60, where routes may be associated with a 
metric); and 

advertising the updated routing information to a network device (column 15, lines 
49-51 , where routes may be advertised). 

Pesce does not expressly teach a client setting an export limit for the device. Sankaran 
teaches a method for managing discard algorithms comprising: 

maintaining a count of routes exported (paragraph 35, where a threshold may be 
reached); and 

rejecting additional routes exported when the count exceeds the export limit set 
by the command (paragraph 45, where additional routes may be discarded once a 
threshold is reached). 

It would have been obvious to one of ordinary skill in the art at the time of the invention 
to utilize a route count and rejecting such as taught by Sankaran in a routing system 
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such as taught by Pesce. Pesce's system generally allows for routes to be exported 
from one protocol operating on a network element to another protocol operating on a 
network element. Pesce further allows for blocking routes by a manager (column 4, 
lines 52-61). It would be beneficial in such a system to utilize a threshold and count of 
routes for blocking, as the routing manager may operate under blocking conditions after 
a threshold of a table is reached, such as a percentage of the memory being used 
(paragraph 45). 

Neither Pesce nor Sankaran teaches a user defined size threshold. Gaddis teaches a 
method for improving databases comprising: 

receiving a command from a client to specify a limit for a table size (column 17, 
lines 29-34, where a prefix limit may be set for injected routes). 
It would have been obvious to utilize a user defined limit such as that taught by Gaddis 
in a system for exporting routes such as that taught by either Pesce or Sankaran. 
Pesce's system generally allows for routes to be exported according to definitions by a 
user, including those determining whether routes may be exported (column 7, lines 11- 
14). Pesce's system also allows a manager to determine when blocking conditions 
occur (column 4, lines 52-61 ). It would be beneficial to allow for a user to determine a 
maximum number of routes, such as taught by Sankaran, as the routing manager may 
operate under blocking conditions after a threshold of a table is reached, such as a 
percentage of the memory being used (paragraph 45). It would further be beneficial for 
a user to determine the maximum, such as taught by Gaddis, this allows the user to set 
further rules regarding route exporting, in addition to those as taught by Pesce. 
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7. As per claim 27, Pesce teaches a computer-readable medium comprising 
instructions to cause a processor to: 

present a management interface to receive a command from a client (column 7, 
lines 11-14, where a user may set rules governing route exportation); 

receive a command, from the client through the management interface, to specify 
rules for routes exported from an exterior routing protocol executing on a network 
device to an interior routing protocol executing on the network device (column 7, lines 
11-14, where a user may set rules governing route exportation); 

maintain rules of routes exported from an exterior routing protocol executing on 
the network device to a plurality of instances of an interior routing protocol executing on 
the network device (column 7, lines 11-14, where a user may set rules governing route 
exportation, also column 2, lines 51-64, where the network element may contain 
multiple routing databases including those that may run both interior and exterior routing 
protocols, also column 3, lines 23-28, where the routing information may be exported 
from one database operating in one protocol to another database operating in another 
protocol); and 

identify one of the instances of the interior routing protocol to which the routes 
were exported (column 2, lines 51-64, where the network element may contain multiple 
routing databases including those that may run both interior and exterior routing 
protocols, also column 3, lines 23-28, where the routing information may be exported 
from one database operating in one protocol to another database operating in another 
protocol); 
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compare the rule for the identified one of the instances to an export limit (column 
7, lines 11-14, where a user may set rules governing route exportation, also column 2, 
lines 51-64, where the network element may contain multiple routing databases 
including those that may run both interior and exterior routing protocols, also column 3, 
lines 23-28, where the routing information may be exported from one database 
operating in one protocol to another database operating in another protocol); and 

reject additional routes to be exported from the exterior routing protocol to the 
identified one of the instances based on the comparison (column 4, lines 52-61, where 
the updated mappings may be blocked by the manager). 

Pesce does not expressly teach a client setting an export limit for the device. Sankaran 
teaches a method for managing discard algorithms comprising: 

maintaining a count of routes exported (paragraph 35, where a threshold may be 
reached); and 

rejecting additional routes exported when the count exceeds the export limit set 
by the command (paragraph 45, where additional routes may be discarded once a 
threshold is reached). 

It would have been obvious to one of ordinary skill in the art at the time of the invention 
to utilize a route count and rejecting such as taught by Sankaran in a routing system 
such as taught by Pesce. Pesce's system generally allows for routes to be exported 
from one protocol operating on a network element to another protocol operating on a 
network element. Pesce further allows for blocking routes by a manager (column 4, 
lines 52-61). It would be beneficial in such a system to utilize a threshold and count of 
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routes for blocking, as the routing manager may operate under blocking conditions after 
a threshold of a table is reached, such as a percentage of the memory being used 
(paragraph 45). 

Neither Pesce nor Sankaran teaches a user defined size threshold. Gaddis teaches a 
method for improving databases comprising: 

receiving a command from a client to specify a limit for a table size (column 17, 
lines 29-34, where a prefix limit may be set for injected routes). 
It would have been obvious to utilize a user defined limit such as that taught by Gaddis 
in a system for exporting routes such as that taught by either Pesce or Sankaran. 
Pesce's system generally allows for routes to be exported according to definitions by a 
user, including those determining whether routes may be exported (column 7, lines 11- 
14). Pesce's system also allows a manager to determine when blocking conditions 
occur (column 4, lines 52-61 ). It would be beneficial to allow for a user to determine a 
maximum number of routes, such as taught by Sankaran, as the routing manager may 
operate under blocking conditions after a threshold of a table is reached, such as a 
percentage of the memory being used (paragraph 45). It would further be beneficial for 
a user to determine the maximum, such as taught by Gaddis, this allows the user to set 
further rules regarding route exporting, in addition to those as taught by Pesce. 
8. As per claim 30, Sankaran further teaches updating muting information to 
associate the routes with a maximum metric that defines a maximum distance from the 
network device to neighboring network devices when the count exceeds the export limit 
(paragraph 5, where the redundant routes may be preferenced by distance); and 
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advertising the updated routing information to a network device (paragraph 3, where the 
network may redefine paths using BGP or OSPF); 

updating routing information when the count exceeds the limit to clear the routes 
exported (paragraph 45, where routes may be deleted from the table when a limit is 
reached or exceeded). 

Pesce further teaches waiting for user intervention before accepting routes (column 7, 
lines 11-14, where a user may set rules governing route exportation). 
9. As per claim 8, Pesce teaches a method comprising: 

an export rule and an associated one of a plurality of instances of an interior 
routing protocol executing on a network device (column 7, lines 11-14, where a user 
may set rules governing route exportation, also column 2, lines 51-64, where the 
network element may contain multiple routing databases including those that may run 
both interior and exterior routing protocols, also column 3, lines 23-28, where the routing 
information may be exported from one database operating in one protocol to another 
database operating in another protocol); 

maintaining rules of routes exported from an exterior routing protocol executing 
on the network device to each of the instances of the interior routing protocol executing 
on the network device (column 7, lines 11-14, where a user may set rules governing 
route exportation, also column 2, lines 51-64, where the network element may contain 
multiple routing databases including those that may run both interior and exterior routing 
protocols, also column 3, lines 23-28, where the routing information may be exported 
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from one database operating in one protocol to another database operating in another 
protocol); 

identifying one of the instances of the interior routing protocol to which the routes 
were exported (column 7, lines 11-14, where a user may set rules governing route 
exportation, also column 2, lines 51-64, where the network element may contain 
multiple routing databases including those that may run both interior and exterior routing 
protocols, also column 3, lines 23-28, where the routing information may be exported 
from one database operating in one protocol to another database operating in another 
protocol); 

comparing the rules for the identified one of the instances to the rule specified by 
the command for the identified instance (column 7, lines 11-14, where a user may set 
rules governing route exportation, also column 2, lines 51-64, where the network 
element may contain multiple routing databases including those that may run both 
interior and exterior routing protocols, also column 3, lines 23-28, where the routing 
information may be exported from one database operating in one protocol to another 
database operating in another protocol); and 

rejecting additional routes exported to the identified one of the instances of the 
interior routing protocol based on the comparison when the rule determines (column 4, 
lines 52-61, where the updated mappings may be blocked by the manager). 
Pesce does not expressly teach a client setting an export limit for the device. Sankaran 
teaches a method for managing discard algorithms comprising: 
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maintaining a count of routes exported (paragraph 35, where a threshold may be 
reached); and 

rejecting additional routes exported when the count exceeds the export limit set 
by the command (paragraph 45, where additional routes may be discarded once a 
threshold is reached). 

It would have been obvious to one of ordinary skill in the art at the time of the invention 
to utilize a route count and rejecting such as taught by Sankaran in a routing system 
such as taught by Pesce. Pesce's system generally allows for routes to be exported 
from one protocol operating on a network element to another protocol operating on a 
network element. Pesce further allows for blocking routes by a manager (column 4, 
lines 52-61). It would be beneficial in such a system to utilize a threshold and count of 
routes for blocking, as the routing manager may operate under blocking conditions after 
a threshold of a table is reached, such as a percentage of the memory being used 
(paragraph 45). 

Neither Pesce nor Sankaran teaches a user defined size threshold. Gaddis teaches a 
method for improving databases comprising: 

receiving a prefix limit command from a client to specify a limit for a table size 
(column 17, lines 29-34, where a prefix limit may be set for injected routes). 
It would have been obvious to utilize a user defined limit such as that taught by Gaddis 
in a system for exporting routes such as that taught by either Pesce or Sankaran. 
Pesce's system generally allows for routes to be exported according to definitions by a 
user, including those determining whether routes may be exported (column 7, lines 11- 
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14). Pesce's system also allows a manager to determine when blocking conditions 
occur (column 4, lines 52-61 ). It would be beneficial to allow for a user to determine a 
maximum number of routes, such as taught by Sankaran, as the routing manager may 
operate under blocking conditions after a threshold of a table is reached, such as a 
percentage of the memory being used (paragraph 45). It would further be beneficial for 
a user to determine the maximum, such as taught by Gaddis, this allows the user to set 
further rules regarding route exporting, in addition to those as taught by Pesce. 
1 0. As per claim 1 1 , Pesce teaches a method comprising: 

exporting routes from an exterior routing protocol process executing on the 
network device to an interior routing protocol process executing on the network device 
(column 2, lines 51-64, where the network element may contain multiple routing 
databases including those that may run both interior and exterior routing protocols, also 
column 3, lines 23-28, where the routing information may be exported from one 
database operating in one protocol to another database operating in another protocol); 
and 

the network device: (i) updates routing information of the interior routing protocol 
to clear the routes previously exported from the exterior routing protocol, (ii) rebuilds the 
routing information of the interior routing protocol by updating the routing information of 
the interior routing protocol to associate interior routes with a maximum metric that 
defines a maximum distance from the network device to neighboring network devices, 
and (iii) advertises the updated routing information to another network device (column 5, 
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lines 14-16, where each entry in the table may be associated with a metric value and 
scale, also column 1 1 , lines 52-60, where routes may be associated with a metric). 
Pesce does not expressly teach a client setting an export limit for the device. Sankaran 
teaches a method for managing discard algorithms comprising: 

maintaining a count of routes exported (paragraph 35, where a threshold may be 
reached); and 

rejecting additional routes exported when the count exceeds the export limit set 
by the command (paragraph 45, where additional routes may be discarded once a 
threshold is reached). 

It would have been obvious to one of ordinary skill in the art at the time of the invention 
to utilize a route count and rejecting such as taught by Sankaran in a routing system 
such as taught by Pesce. Pesce's system generally allows for routes to be exported 
from one protocol operating on a network element to another protocol operating on a 
network element. Pesce further allows for blocking routes by a manager (column 4, 
lines 52-61). It would be beneficial in such a system to utilize a threshold and count of 
routes for blocking, as the routing manager may operate under blocking conditions after 
a threshold of a table is reached, such as a percentage of the memory being used 
(paragraph 45). 

Neither Pesce nor Sankaran teaches a user defined size threshold. Gaddis teaches a 
method for improving databases comprising: 

receiving a prefix limit command from a client to specify a limit for a table size 
(column 17, lines 29-34, where a prefix limit may be set for injected routes). 
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It would have been obvious to utilize a user defined limit such as that taught by Gaddis 
in a system for exporting routes such as that taught by either Pesce or Sankaran. 
Pesce's system generally allows for routes to be exported according to definitions by a 
user, including those determining whether routes may be exported (column 7, lines 11- 
14). Pesce's system also allows a manager to determine when blocking conditions 
occur (column 4, lines 52-61 ). It would be beneficial to allow for a user to determine a 
maximum number of routes, such as taught by Sankaran, as the routing manager may 
operate under blocking conditions after a threshold of a table is reached, such as a 
percentage of the memory being used (paragraph 45). It would further be beneficial for 
a user to determine the maximum, such as taught by Gaddis, this allows the user to set 
further rules regarding route exporting, in addition to those as taught by Pesce. 

11. As per claim 12, Sankaran further teaches: 

an export limit indicative of a maximum number of routes that can be exported 
(paragraph 29, where a threshold may be established); 

comparing the counted number of routes to the export limit (paragraph 35, where 
a threshold may be reached); and 

rejecting additional routes exported when the counted number of routes exceeds 
the export limit (paragraph 45, where additional routes may be discarded once a 
threshold is reached). 

12. As per claim 1 3, Pesce further teaches waiting for user intervention before 
accepting routes (column 7, lines 11-14, where a user may set rules governing route 
exportation). 
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13. As per claim 15, Sankaran further teaches updating routing information when the 
count exceeds the limit to clear the routes exported (paragraph 45, where routes may 
be deleted from the table when a limit is reached or exceeded). 

14. As per claim 18, Pesce teaches a system comprising: 

routes exported from an external routing protocol executing on a network device 
to an interior routing protocol executing on the network device in accordance with the 
export limit (column 2, lines 51-64, where the network element may contain multiple 
routing databases including those that may run both interior and exterior routing 
protocols, also column 3, lines 23-28, where the routing information may be exported 
from one database operating in one protocol to another database operating in another 
protocol); and 

a plurality of instances of the interior routing protocol executing on the system 
(column 2, lines 51-64, where the network element may contain multiple routing 
databases including those that may run both interior and exterior routing protocols, also 
column 3, lines 23-28, where the routing information may be exported from one 
database operating in one protocol to another database operating in another protocol), 

wherein the control unit separately exports to each of the instances (column 2, 
lines 51-64, where the network element may contain multiple routing databases 
including those that may run both interior and exterior routing protocols, also column 3, 
lines 23-28, where the routing information may be exported from one database 
operating in one protocol to another database operating in another protocol), and 
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wherein the control unit identifies an instance of the interior routing protocol to 
which routes were exported, accesses the respective rule, and rejects additional routes 
exported from the exterior routing protocol to the identified instance based on the 
comparison (column 7, lines 11-14, where a user may set rules governing route 
exportation). 

Pesce does not expressly teach a client setting an export limit for the device. Sankaran 
teaches a method for managing discard algorithms comprising: 

maintaining a count of routes exported (paragraph 35, where a threshold may be 
reached); and 

rejecting additional routes exported when the count exceeds the export limit set 
by the command (paragraph 45, where additional routes may be discarded once a 
threshold is reached). 

It would have been obvious to one of ordinary skill in the art at the time of the invention 
to utilize a route count and rejecting such as taught by Sankaran in a routing system 
such as taught by Pesce. Pesce's system generally allows for routes to be exported 
from one protocol operating on a network element to another protocol operating on a 
network element. Pesce further allows for blocking routes by a manager (column 4, 
lines 52-61). It would be beneficial in such a system to utilize a threshold and count of 
routes for blocking, as the routing manager may operate under blocking conditions after 
a threshold of a table is reached, such as a percentage of the memory being used 
(paragraph 45). 
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Neither Pesce nor Sankaran teaches a user defined size threshold. Gaddis teaches a 
method for improving databases comprising: 

receiving a prefix limit command from a client to specify a limit for a table size 
(column 17, lines 29-34, where a prefix limit may be set for injected routes). 
It would have been obvious to utilize a user defined limit such as that taught by Gaddis 
in a system for exporting routes such as that taught by either Pesce or Sankaran. 
Pesce's system generally allows for routes to be exported according to definitions by a 
user, including those determining whether routes may be exported (column 7, lines 11- 
14). Pesce's system also allows a manager to determine when blocking conditions 
occur (column 4, lines 52-61 ). It would be beneficial to allow for a user to determine a 
maximum number of routes, such as taught by Sankaran, as the routing manager may 
operate under blocking conditions after a threshold of a table is reached, such as a 
percentage of the memory being used (paragraph 45). It would further be beneficial for 
a user to determine the maximum, such as taught by Gaddis, this allows the user to set 
further rules regarding route exporting, in addition to those as taught by Pesce. 

1 5. As per claim 1 9, Gaddis further teaches a prefix counter to count the routes 
exported to the interior routing protocol and generate a prefix count, wherein the control 
unit compares the prefix count to the export limit and limits the number of routes 
exported to the interior routing protocol based on the comparison (column 17, lines 29- 
34, where a prefix limit may be set for injected routes). 

16. As per claim 20, Gaddis further teaches rejecting additional routes to be exported 
to the interior routing protocol when the prefix count exceeds the export limit (column 
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17, lines 29-34, where a prefix limit may be set for injected routes, and routes may be 
filtered by prefix count). 

1 7. As per claim 21 , no reference expressly teaches the exterior routing protocol 
supports a larger number of routes than the interior routing protocol. However, Pesce 
teaches that BGP may be utilized with OSPF on a network element. BGP protocols 
maintain routes between ASes, therefore is theoretically capable of maintaining routing 
information to all systems on a network. OSPF is used within an AS, and therefore 
maintains routing information only with a selection of computers on the greater network 

18. As per claim 22, Gaddis further teaches communicating with an internet service 
provider via the exterior routing protocol (column 1, lines 20-27, where common 
connections utilize ISPs). 

1 9. As per claim 26, Pesce further teaches the system comprises a router (Figure 1 ). 

20. As per claim 33, Pesce teaches a method comprising: 

directing a network device to export routes from an exterior routing protocol 
executing on the network device to an interior routing protocol executing on the network 
device (column 2, lines 51-64, where the network element may contain multiple routing 
databases including those that may run both interior and exterior routing protocols, also 
column 3, lines 23-28, where the routing information may be exported from one 
database operating in one protocol to another database operating in another protocol); 

receiving an export rule for routes that may be exported from the exterior routing 
protocol to a specific instance of the interior routing protocol (column 7, lines 11-14, 
where a user may set rules governing route exportation); 
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exporting routes from the exterior routing protocol to the specific instance of the 
interior routing protocol (column 2, lines 51-64, where the network element may contain 
multiple routing databases including those that may run both interior and exterior routing 
protocols, also column 3, lines 23-28, where the routing information may be exported 
from one database operating in one protocol to another database operating in another 
protocol); 

blocking routes from the exterior routing protocol if the rule determines the route 
should not be exported (column 4, lines 52-61, where the updated mappings may be 
blocked by the manager). 

Pesce does not expressly teach a client setting an export limit for the device. Sankaran 
teaches a method for managing discard algorithms comprising: 

maintaining a count of routes exported (paragraph 35, where a threshold may be 
reached); and 

rejecting additional routes exported when the count exceeds the export limit set 
by the command (paragraph 45, where additional routes may be discarded once a 
threshold is reached). 

It would have been obvious to one of ordinary skill in the art at the time of the invention 
to utilize a route count and rejecting such as taught by Sankaran in a routing system 
such as taught by Pesce. Pesce's system generally allows for routes to be exported 
from one protocol operating on a network element to another protocol operating on a 
network element. Pesce further allows for blocking routes by a manager (column 4, 
lines 52-61). It would be beneficial in such a system to utilize a threshold and count of 
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routes for blocking, as the routing manager may operate under blocking conditions after 
a threshold of a table is reached, such as a percentage of the memory being used 
(paragraph 45). 

Neither Pesce nor Sankaran teaches a user defined size threshold. Gaddis teaches a 
method for improving databases comprising: 

receiving a prefix limit command from a client to specify a limit for a table size 
(column 17, lines 29-34, where a prefix limit may be set for injected routes). 
It would have been obvious to utilize a user defined limit such as that taught by Gaddis 
in a system for exporting routes such as that taught by either Pesce or Sankaran. 
Pesce's system generally allows for routes to be exported according to definitions by a 
user, including those determining whether routes may be exported (column 7, lines 11- 
14). Pesce's system also allows a manager to determine when blocking conditions 
occur (column 4, lines 52-61 ). It would be beneficial to allow for a user to determine a 
maximum number of routes, such as taught by Sankaran, as the routing manager may 
operate under blocking conditions after a threshold of a table is reached, such as a 
percentage of the memory being used (paragraph 45). It would further be beneficial for 
a user to determine the maximum, such as taught by Gaddis, this allows the user to set 
further rules regarding route exporting, in addition to those as taught by Pesce. 
21 . As per claim 39, Pesce further teaches the management interface receives the 
command from a remote client (column 7, lines 11-14, where a user may set rules 
governing route exportation). 
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22. As per claim 40, Pesce further teaches the remote client comprises one of a 
human user and an automated script (column 7, lines 11-14, where a user may set rules 
governing route exportation). 

23. Claims 6 and 32 are rejected under 35 U.S.C. 103(a) as being unpatentable over 
US 7 328 278, Pesce et al, US 2003/0231587, Sankaran et al, and US 7 554 930, 
Gaddis et al as applied to claims above, and further in view of US 6 212 188, 
Rochberger et al. 

24. As per claim 6, neither reference teaches a method to update the routing 
information in response to a state change of the device. Rochberger teaches a method 
of routing in a network when a node is in overload state comprising: 

updating routing information to set an overload bit of a link state prefix associated 
with the routes when the count exceeds the export limit (Column 2, lines 8-14, 
where the state information is contained in PTSE messages. Along with column 
5, lines 30-35, where the overloaded node sends a PTSE message to other 
nodes notifying itself as being overloaded, it is inherent that the PTSE contains 
the overload information, and is changed when the node goes into overload 
status); and 

advertising the updated routing information to a network device (Column 5, lines 
30-35, where the overloaded node sends a message to other nodes notifying 
itself as being overloaded). 
It would have been obvious to one of ordinary skill in the art at the time of the invention 
to include an overload notification such as that described by Rochberger in a network 
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system such as that taught by Sankaran or Pesce. Pesce's system would benefit, as the 
routing protocols could notify others when they are reached, relieving the processing 
required to process routes. Sankaran's system would benefit, as it could notify other 
devices when the address limit within a table has been reached, relieving the 
processing required for rejecting additional addresses sent. The notification method 
described by Rochberger can be used in any system, as it only describes how a node 
reacts to being in an overload state, and does not affect the performance of the node in 
normal functions. This would allow the notification method to be used in any system, 
including that taught by Sankaran or Pesce. 

25. As per claim 32, neither reference teaches a method to update the routing 
information in response to a state change of the device. Rochberger teaches a method 
of routing in a network when a node is in overload state comprising: 

updating routing information to set an overload bit of a link state prefix associated 
with the routes when the count exceeds the export limit (Column 2, lines 8-14, 
where the state information is contained in PTSE messages. Along with column 
5, lines 30-35, where the overloaded node sends a PTSE message to other 
nodes notifying itself as being overloaded, it is inherent that the PTSE contains 
the overload information, and is changed when the node goes into overload 
status); and 

advertising the updated routing information to a network device (Column 5, lines 
30-35, where the overloaded node sends a message to other nodes notifying 
itself as being overloaded). 
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It would have been obvious to one of ordinary skill in the art at the time of the invention 
to include an overload notification such as that described by Rochberger in a network 
system such as that taught by Sankaran or Pesce. Pesce's system would benefit, as the 
routing protocols could notify others when they are reached, relieving the processing 
required to process routes. Sankaran's system would benefit, as it could notify other 
devices when the address limit within a table has been reached, relieving the 
processing required for rejecting additional addresses sent. The notification method 
described by Rochberger can be used in any system, as it only describes how a node 
reacts to being in an overload state, and does not affect the performance of the node in 
normal functions. This would allow the notification method to be used in any system, 
including that taught by Sankaran or Pesce. 

Conclusion 

26. THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time 
policy as set forth in 37 CFR 1 .136(a). 

A shortened statutory period for reply to this final action is set to expire THREE 
MONTHS from the mailing date of this action. In the event a first reply is filed within 
TWO MONTHS of the mailing date of this final action and the advisory action is not 
mailed until after the end of the THREE-MONTH shortened statutory period, then the 
shortened statutory period will expire on the date the advisory action is mailed, and any 
extension fee pursuant to 37 CFR 1 .136(a) will be calculated from the mailing date of 
the advisory action. In no event, however, will the statutory period for reply expire later 
than SIX MONTHS from the mailing date of this final action. 
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Any inquiry concerning this communication or earlier communications from the 
examiner should be directed to THOMAS RICHARDSON whose telephone number is 
(571 ) 270-1 1 91 . The examiner can normally be reached on Monday through Thursday, 
8am-5pm EST. 

If attempts to reach the examiner by telephone are unsuccessful, the examiner's 
supervisor, William Vaughn can be reached on (571) 272-3922. The fax phone number 
for the organization where this application or proceeding is assigned is 571-273-8300. 

Information regarding the status of an application may be obtained from the 
Patent Application Information Retrieval (PAIR) system. Status information for 
published applications may be obtained from either Private PAIR or Public PAIR. 
Status information for unpublished applications is available through Private PAIR only. 
For more information about the PAIR system, see http://pair-direct.uspto.gov. Should 
you have questions on access to the Private PAIR system, contact the Electronic 
Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a 
USPTO Customer Service Representative or access to the automated information 
system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000. 

TR 

/William C. Vaughn, Jr./ 

Supervisory Patent Examiner, Art Unit 2444 



